…DEFAULTS

#### Description

Add a `"recovery": 600` (10 min) entry to `ModuleBase._TRANSITION_TIMEOUT_DEFAULTS`.

`set_module_state_transition()` validates the requested `transition_type` against the keys of `_TRANSITION_TIMEOUT_DEFAULTS`. chassisd's DPU power-cycle auto-recovery acquires the module state-transition lock via `set_module_state_transition(name, 'recovery')`; because `'recovery'` was missing from the defaults, every recovery acquisition was rejected ("Cannot acquire state transition lock") and the power-cycle was silently skipped — blocking DPU auto-recovery.

#### Motivation and Context

The `'recovery'` transition type is used by chassisd (sonic-platform-daemons) to power-cycle an unresponsive DPU. Without a matching entry in `_TRANSITION_TIMEOUT_DEFAULTS`, the transition is never accepted, so a DPU that loses its control plane is never power-cycled. This unblocks the DPU auto-recovery path in sonic-net/sonic-platform-daemons#829.

`recovery` has no `platform.json` override (only `startup`/`shutdown`/`reboot`/`halt_services` are overridable in `_load_transition_timeouts()`), so the 600 s default applies uniformly. The timeout only bounds the power-cycle critical section (pre_shutdown → admin down → admin up → post_startup), which is cleared in `finally`; 600 s is ample headroom.

#### How Has This Been Tested?

- Unit tests: updated the timeout-loading tests in `tests/module_base_test.py` to expect the new key. `python3 -m pytest tests/module_base_test.py` → **115 passed**.
- On-device with both master and 202605 image: with the fix, a control-plane-down DPU was power-cycled (reboot-cause "Switch rebooted DPU") and recovered to `ready_status=true`.

#### Additional Information (Optional)

Companion to sonic-net/sonic-platform-daemons#829 (chassisd DPU auto-recovery robustness), which issues the `'recovery'` transition this default enables.

Signed-off-by: Sonic Build Admin <sonicbld@microsoft.com>